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Abstract 

This  paper  discusses  the  use  of  the  Ptides  model  of  computation  as  a  coordination  language 
for  the  design  of  deterministic,  event-driven,  real-time,  distributed  embedded  systems.  Specif¬ 
ically,  the  paper  shows  how  the  use  of  synchronized  clocks  in  the  context  of  Ptides  enables 
explicit,  platform  independent  specification  of  functionality  and  timing.  From  this  specification, 
we  generate  code  for  two  target  platforms:  Renesas  and  XMOS.  The  generated  code  includes  a 
lightweight  operating  system  which  performs  scheduling,  I/O  and  network  handling  as  well  as 
application  specific  tasks. 

Ptides  models  are  developed  in  Ptolemy,  a  design  and  simulation  environment  for  heteroge¬ 
neous  systems.  This  framework  also  contains  a  code  generation  framework  which  is  leveraged 
to  derive  Ptides  implementations  from  the  models.  We  illustrate  our  approach  by  designing 
a  simple  Ptides  application,  a  small  component  in  a  printing  press  responsible  for  on-the-fly 
changeover  between  paper  rolls.  We  demonstrate  the  design  process  and  show  that  the  gener¬ 
ated  code  exhibits  identical  timing  at  the  cyber-physical  boundary  on  multiple  implementation 
platforms.  1 


1  Introduction 

This  paper  discusses  the  use  of  the  Ptides  model  of  computation  (MoC)  [1]  as  a  coordination  lan¬ 
guage  [2]  for  the  design  of  deterministic,  event-driven,  real-time,  distributed  embedded  systems. 
Such  systems  are  common  in  industrial  and  commercial  systems  and  typically  include  sensors,  ac¬ 
tuators  and  computing  elements,  often  on  different  platforms,  communicating  via  a  network.  The 
timing  of  sensing  and  actuation  is  often  critical  when  the  system  is  used  to  control  or  monitor 
external  processes.  Timing  requirements  for  accuracy  and  precision  are  very  application  depen¬ 
dent  and  range  from  milliseconds  for  many  devices,  microseconds  for  high  speed  machinery  and 
telecommunications,  and  nanoseconds  or  better  for  some  military  and  scientific  applications. 

We  illustrate  how  the  Ptides  methodology  allows  the  system  or  device  designer  to  explicitly 
specify  both  the  functional  and  the  external  timing  properties  of  a  device  or  system  in  a  platform 
independent  manner.  We  also  show  how,  with  simple  constraints,  synchronized  clocks  with  addi¬ 
tional  hardware  support  allow  enforcement  of  highly  accurate  and  precise  timing  constraints  that 

1This  work  was  supported  in  part  by  the  iCyPhy  Research  Center  (Industrial  Cyber-Physical  Systems,  supported 
by  IBM  and  United  Technologies),  and  the  Center  for  Hybrid  and  Embedded  Software  Systems  (CHESS)  at  UC 
Berkeley  (supported  by  the  National  Science  Foundation,  NSF  awards  #0720882  (CSR-EHS:  PRET)  and  #0931843 
(ActionWebs),  the  Naval  Research  Laboratory  (NRL  #N0013-12-1-G015),  and  the  following  companies:  Bosch, 
National  Instruments,  and  Toyota). 

Special  thanks  go  to  Siemens  for  a  grant  and  to  National  Semiconductor,  XMOS,  Renesas  and  National  Instruments 
for  equipment  grants. 
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are  independent  of  the  execution  times  of  the  embedded  code.  These  characteristics  should  alle¬ 
viate  current  problems  in  maintaining  interfaces,  especially  timing  interfaces,  under  code  updates 
in  devices  or  device  upgrades  in  systems.  We  extend  previous  work  [3]  by  reporting  experimental 
data  illustrating  the  properties  of  this  approach  and  discussing  the  role  of  supporting  hardware. 
Modeling,  simulation  and  code  generation  is  implemented  in  Ptolemy  II,  [4],  an  academic  tool  for 
designing  and  experimenting  with  heterogeneous  system  models. 

The  first  section  of  this  paper  provides  a  basic  understanding  of  the  Ptolemy  II  system  and 
the  Ptides  extension.  The  second  section  discusses  the  basics  of  Ptolemy  II,  the  Ptides  model  and 
describes  how  to  construct  applications.  The  third  section  discusses  the  use  of  Ptides  as  well  as  the 
design  and  execution  environment.  The  fourth  section  illustrates  the  process  via  a  simple  controller 
design,  and  an  experimental  verification  of  the  timing.  The  paper  concludes  with  a  summary  and 
a  brief  outlook  on  future  work. 

2  Ptolemy  II  and  Ptides  basics 

Ptolemy  II  is  a  modeling  and  simulation  framework  for  concurrent  models  of  computation  (MoC) 
and  heterogeneous  mixtures  of  MoCs.  MoCs  that  are  implemented  in  Ptolemy  include  discrete-event 
(DE),  continuous  time  (CT),  synchronous  reactive,  dataflow  and  process  networks.  We  implement 
Ptides  in  Ptolemy  as  a  DE-based  MoC.  CT  is  typically  used  to  represent  physical  processes.  This 
allows  for  co-simulation  of  plant  models  with  Ptides  designed  control  systems  to  study  the  functional 
and  timing  properties  of  the  entire  system.  A  DE  model  [5]  was  selected  for  Ptides  because  DE 
systems  executing  tokens  in  timestamp  order  have  the  property  that  given  a  set  of  input  tokens, 
all  correct  DE  implementations  will  produce  identical  sets  of  output  tokens  [6]. 

2.1  Actor-oriented  design 

Ptolemy  follows  the  actor-oriented  design  principle  [7]  and  graphically  represents  models  where 
actors  appear  to  a  designer  using  the  Ptolemy  graphical  editor  as  boxes  with  ports  as  illustrated 
in  the  center  panel  of  Figure  1. 

All  communication  between  actors  is  via  tokens  passed  between  ports.  In  a  Ptides  design 
these  tokens  are  a  (value,  timestamp,  microstep)  triple.  The  (timestamp,  microstep)  pair  models 
a  superdense  formulation  of  time  where  the  timestamp  represents  model  time  and  the  microstep 
allows  ordering  of  events  with  identical  values  of  the  model  time  [8]. 

The  model  of  computation  used  by  a  model  is  determined  by  the  Director2  component  which 
governs  the  Ptolemy  simulation  engine  as  well  as  specifying  the  code  generation  MoC,  in  this 
case  DE.  In  this  model  the  DiscreteClock  actor  generates  periodic  events  with  tokens  (1,0,1)  and 
(0,100,1)  repeating  with  a  period  of  200  so  that  the  initial  (time  0)  set  point  is  1  which  then  changes 
to  0  at  time  100. 

Ptolemy  models  can  be  hierarchical  as  illustrated  by  the  top  and  bottom  panels.  The  top  panel 
is  a  CT  model  of  the  Plant  Model  actor  and  implements  the  integral  equation  ( RC)xT  =  f  (D-T)dt 
where  T  is  the  Tachometer  Output  variable  and  D  is  the  Drivelnput  variable.  For  constant  D  =  Dq 
the  solution  is  T  =  Dq(1  —  e~^RC).  The  ZeroOrderHold  and  PeriodicS ampler  actors  are  required 
since  the  tokens  representing  the  variables  D  and  T  cross  the  boundary  between  the  CT  and  DE 

2  Italic  fonts  indicate  names  of  artifacts  in  the  figures. 
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domain  in  the  hierarchy.  The  symbol  labeled  RC  10.0  specifies  the  parameter  RC  with  a  value  of 
10.  The  other  actors  have  their  obvious  interpretation. 

The  bottom  panel  illustrates  the  model  for  the  controller.  In  this  case  the  PtidesDirector  actor 
specifies  that  Ptides  semantics,  a  specialization  of  DE  semantics,  are  enforced.  Ptides  semantics 
are  embodied  in  five  special  actors: 

•  Sensor  ports  are  illustrated  by  the  SetPoint  and  Tachometer  ports  in  the  bottom  panel  of 
Figure  1.  A  Ptides  sensor  port  takes  the  value  of  the  sensor  input,  S±,  at  time,  t\,  and  places 
an  event  token  (Si,fi,l)  on  the  event  queue.  When  this  model  is  executed  using  the  Ptolemy 
simulator,  the  time  t\  is  the  sample  time  modeled  by  the  top  level  DE  director  and  represents 
physical  time  in  the  simulation.  In  code  generated  from  this  model,  t\  is  in  the  frame  of 
reference  of  the  platform’s  real-time  clock. 

•  Actuator  ports  are  illustrated  by  the  SetPointMonitor  and  Drive  ports.  A  Ptides  actuator 
port  takes  an  input  token  (A2,t2d)  at  its  input  and  instantiates  the  value  A 2  at  the  actuator 
output  at  a  time  t.2  where  t2  is  the  time  in  the  frame  of  reference  of  the  top  level  DE  director 
in  simulation  and  of  the  platform’s  real-time  clock  in  a  physical  implementation. 

•  A  network  output  port,  (not  illustrated  in  Figure  1),  takes  an  input  token  ( V3 ,t3,i)  from  its 
input  and  embeds  it  in  a  message  on  the  external  network  at  a  time  tno  in  the  frame  of 
reference  of  the  top  level  DE  director  in  simulation  and  of  the  platform’s  real-time  clock  in 
a  physical  implementation.  tno  is  a  parameter  of  the  port  and  allows  the  designer  to  specify 
the  value  as  a  time  offset  from  the  time  of  origin  of  upstream  events,  typically  a  sensor  input 
port. 

•  A  network  input  port,  (not  illustrated  in  Figure  1),  extracts  the  token  ( V3 ,^3 ,i)  from  the 
message  received  from  the  external  network  and  places  it  on  the  local  event  queue  at  a  time 
tni .  The  offset  between  tno  on  the  sending  platform  and  tni  is  a  function  of  the  network 
protocol  and  typically  the  network  traffic  load. 

•  Time  delay  actors  are  illustrated  by  the  TimeDelay  and  TimeDelay2  actors.  A  Ptides  time 
delay  actor  takes  an  input  token  (V4,f4,i)  at  its  input  and  outputs  a  token  (V4,t4  +  tdeiay-S)- 
The  value  of  tdeiay  can  be  set  as  a  parameter  or  taken  from  the  bottom  input  port  of  the 
actor.  This  actor  permits  the  designer  to  specify  the  time  delay  between  sensor  inputs  and 
actuator  outputs.  For  example,  in  Figure  1  a  sensor  reading  at  time  ts  at  the  Tachometer 
input  results  in  an  actuation  by  the  Drive  actuator  at  a  time  ts  +  0.001  where  both  the  times 
ts  and  ts  +  0.001  are  in  the  frame  of  reference  of  the  top  level  DE  director  in  simulation  and 
of  the  platform’s  real-time  clock  in  a  physical  implementation. 

2.2  Timing  considerations 

It  is  easy  to  specify  a  system  that  cannot  meet  its  timing  constraints.  In  the  example  of  Figure 
1  if  tdeiay  =  0  then,  while  the  execution  can  be  simulated,  the  system  cannot  be  executed  in  a 
real  system  since  the  computations  take  a  finite  amount  of  time.  However,  provided  the  specified 
model  delays,  e.g.  using  the  time  delay  actors,  are  greater  than  the  execution  times  on  a  particular 
platform,  then  DE  semantics,  simple  constraints  on  actor  temporal  semantics,  and  the  properties 
of  the  sensor  and  actuator  ports  ensure  that  the  external  timing  meets  the  specification  to  within 
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Figure  1:  Model  of  a  simple  control  system. 


the  accuracy  permitted  by  the  implementation  of  these  ports  irrespective  of  the  actual  execution 
time  [9].  This  is  extremely  important,  since  changes,  such  as  improving  algorithm  performance  or 
using  a  faster  processor,  do  not  change  the  external  timing  performance  of  the  device. 

If  the  sensor  input  and  actuator  output  are  on  different  platforms  communicating  via  a  network, 
the  network  delay  must  be  bounded  and  included  in  the  specification  of  end-to-end  delay  to  ensure 
that  timing  specifications  are  met.  In  networked  systems,  the  real-time  clocks  in  the  various 
platforms  must  be  synchronized  to  the  necessary  degree  of  accuracy,  for  example  via  IEEE  1588 
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[10],  since  the  execution  clearly  depends  on  all  timestamps  at  platform  inputs  and  outputs  using  a 
common  time  reference. 

As  noted,  the  timing  accuracy  depends  on  the  implementation  of  the  Ptides  input  and  output 
ports.  Logically,  sensor  and  actuator  ports  appear  as  illustrated  in  Figure  2.  For  example,  for  an 
analog  sensor,  the  sample  and  hold  trigger  is  generally  used  as  the  sensor  indicator  that  latches  the 
time,  the  sensor  timestamp ,  from  the  real-time  clock  into  the  sensor  timing  register.  Likewise,  an 
actuation  timestamp  placed  in  the  actuator  timing  register  by  Ptides  generated  code  is  compared  to 
the  real-time  clock ,  and  when  the  times  match,  the  actuation  trigger  is  generated.  If  these  functions 
are  implemented  in  hardware,  e.g.  on  an  FPGA,  the  time  accuracy  will  typically  correspond  to  the 
LSB  of  the  clock.  If  implemented  by  code  in  a  microprocessor,  the  accuracy  will  be  determined 
by  interrupt  latencies,  and  execution  time  considerations.  Some  of  these  considerations  can  be 
addressed  by  using  architectures  such  as  XMOS  [11]  or  PRET  [12]  where  execution  times  are 
predictable. 


sensor  timestamp 


actuation  trigger 


Figure  2:  Logical  model  of  sensor  and  actuator  ports 


2.3  Safe-to-process  timing 

A  final  important  execution  issue  in  correctly  executing  DE  semantics  in  real  time  is  illustrated  in 
Figure  3.  Suppose  a  token,  (5^,30, 1),  appears  on  port  b  of  the  AddSubtract  adder.  When  can  the 
adder  execute  given  the  DE  requirement  that  tokens  must  be  processed  in  timestamp  order?  Any 
event  from  sensorC  on  platformA  with  a  timestamp  <  30  will  already  be  in  the  event  queue  for  port 
c.  Consider  an  event  with  timestamp  30  generated  at  sensor  A  on  platformD.  The  sensor Anetwork 
output  port  on  platformD  has  a  platform  delay  bound  value  of  1  ensuring  that  this  event  will  be 
placed  on  the  network  no  later  than  time  30  +  1  relative  to  the  platformD’s  clock.  Assume  the 
network  transit  time  is  bounded  by  a  value  of  5.  Hence  the  event  (5^4,30,1)  must  arrive  at  the 
sensor  Anetwork  input  port  and  be  placed  on  the  event  queue  of  platformA  at  a  time  no  later  than 
30  +  1  +  5  =  36.  Assume  the  maximum  clock  synchronization  error  is  e.  Therefore,  the  AddSubtract 
adder  must  delay  processing  the  event  (Sb,  30, 1)  on  port  b  until  at  least  time  36  +  e  relative  to 
the  clock  on  platformA.  In  analyzing  a  design  for  these  safe  to  process  values,  accurate  values 
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Figure  3:  Safe  to  process  example 


for  network  delays  and  e  are  required.  Note  that  an  event  with  a  timestamp  <  30  arriving  after 
the  computation  can  be  detected  and  appropriate  application  specific  action  taken.  This  may  be 
valuable  in  some  applications. 

3  Design  and  execution  environment 

The  design  and  execution  environment  is  illustrated  in  Figure  4.  The  designer  typically  uses  a 
graphical  editor  to  produce  a  Ptides-based  system  model  as  shown  in  Figure  1. 


(  Schedulability  Analysis  ) 


(  Causality  Analysis 


— (^  Program  Analysis 


(Vtides 


Mod e I Code  GeneratoT^V^X'^ >(Code  +  PtidyOS~)_ 
^  y/  ( Hardware  Platform 


(Software  Component  Library) 


(Mixed  Simulator")-* - (  Plant  Model  ) - ►fcp^mulator] 


(  Network  Model) 


Figure  4:  Ptides  design  environment 

The  model  properties  are  observed  using  a  mixed  MOC  simulator  (one  that  supports  multiple 
MOCs),  in  our  case  the  Ptolemy  simulator.  Once  the  designer  is  satisfied,  the  target  platform  is 
specified  which  in  turn  specifies  platform  specific  versions  of  Ptides  actors,  e.g.  I/O  and  network 
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Figure  5:  Flying  paster 


port  actors.  Causality  analysis  determines  causal  dependencies  in  the  design  to  enable  optimal  DE 
execution  [13].  Schedulability  analysis  determines  whether  the  selected  platform  is  able  to  meet 
the  execution  time  constraints  discussed  in  section  2.2.  The  code  generator  produces  code  that 
executes  on  a  lightweight  OS,  PtidyOS  [14],  that  supports  a  DE  style  of  execution,  the  platform 
specific  I/O  and  network  ports  and  the  synchronization  of  the  platform  real-time  clock  to  its  peers 
in  other  system  platforms.  The  portions  of  PtidyOS  code  that  implement  access  to  the  real-time 
clock,  and  I/O  and  network  ports  is  platform  specific.  For  other  actors  the  PtidyOS  code  is  the 
output  of  standard  compilers  for  the  microprocessor.  This  permits  automatic  generation  of  the 
final  executable  code  from  the  design  models. 

4  Experimental  results 

To  illustrate  the  temporal  properties  of  a  Ptides-based  system,  we  implement  a  controller  for  a 
flying  paster,  which  is  the  device  in  a  printing  press  that  allows  on-the-fly  changeover  from  an 
active  to  a  spare  roll  of  paper.  The  schematic  of  a  flying  paster  is  shown  in  Figure  5  and  a  video 
of  a  flying  paster  in  operation  can  be  found  at  [15]. 

In  Figure  5,  the  current  roll  of  paper  B  feeds  paper,  i.e.  the  web ,  to  the  rest  of  the  machine 
via  an  idler  wheel  C.  A  sensor  H  detects  the  radius  of  the  paper  on  B,  generates  a  signal,  radius , 
and  at  a  designated  value  directs  a  controller  to  bring  the  reserve  roll  A  up  to  speed  such  that  the 
velocity  of  the  paper  at  the  edge  of  A  matches  that  of  the  web.  At  a  specified  minimum  radius, 
sensor  H  generates  an  arming  signal,  arm.  A  sensor  J  detects  the  radius  of  the  paper  on  A.  The 
outer  layer  of  paper  on  A  has  a  strip  of  double  sided  tape  that  can  be  detected  by  sensor  G,  which 
then  generates  a  signal,  tape,  the  first  time  the  tape  is  detected  after  the  arm  signal.  This  event 
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Figure  6:  Flying  paster  controller 


also  causes  the  idler  wheel  E  to  press  the  web  against  the  reserve  roll  A,  such  that  when  the  tape 
reaches  a  point  relative  to  G  by  an  angle  tapeTo  Contact  Angle,  the  two  pieces  of  paper  attach  and 
the  paper  on  A  follows  the  path  of  the  web.  At  the  angle  tapeTo  Cut  Angle  relative  to  G,  the  cutter 
D  cuts  the  paper  feed  from  B  allowing  A  to  supply  paper  to  the  web.  Clearly  tapeTo  Cut  Angle 
must  be  greater  than  tapeTo  Contact  Angle  to  ensure  that  the  reserve  paper  is  attached  to  the  web 
prior  to  cutting  the  feed  from  B.  A  sensor  F  detects  the  top  dead  center  point,  tdc,  on  roll  A. 

To  demonstrate  the  timing  properties  of  Ptides  generated  code,  we  implement  the  controller 
shown  in  Figure  6,  that  accepts  the  sensor  signals  arm,  tdc,  tape,  and  radius ,  and  generates  the 
signals  contact  and  cut  to  drive  the  actuators.  The  controller  also  outputs  the  linear  velocity  of 
the  paper  on  roll  A. 

Recall  from  section  2.1  that  events,  e.g.  arm,  consist  of  a  (valuearm,  timestamparm,  microsteparm) 
triple.  The  Merge  actor  accepts  the  arm  signal  from  the  sensor  and  transmits  it  to  the  MR2  actor. 
The  MR2  actor  has  the  property  that  the  value,  e.g.  valuearm,  of  the  most  recent  token  on  the 
input  is  output  as  the  (valuearm,  timestamp*,  microstep*)  triple  where  timestamp*  and  microstep* 
are  the  timestamp  and  microstep  of  a  token  received  on  the  trigger  port.  This  type  of  actor  has  a 
default  parameter  specifying  a  value,  in  this  case  false,  applied  if  the  trigger  occurs  before  a  token 
is  received  on  the  input.  Therefore,  when  a  tape  signal  is  received  after  the  arm  signal,  the  logic 
generates  the  tape  trigger  event  with  the  timestamp  of  the  tape  event.  The  TimeDelayS  actor 
increments  this  timestamp  and  sends  the  event  to  the  contact  actuator.  A  slight  delay  is  required 
since  these  computations  take  a  finite  amount  of  time  to  execute  and  Ptides  semantics  requires 
that  actuation  occur  when  the  timestamp  and  the  platform  clock  values  match.  This  is  an  example 
of  the  schedulability  requirement  discussed  in  section  3.  The  tape  trigger  event  also  causes  a  false 
event  to  be  fed  back  to  the  Merge  actor,  which  in  turn  sets  the  most  recent  value  in  MR2  to  false 


thus  suppressing  the  generation  of  additional  tape  trigger  events.  The  Micro  step  Delay  actor  incre¬ 
ments  the  microstep  value  of  the  token  and  is  necessary  since  inputs  to  actors,  in  this  case  MR2 , 
by  DE  semantics  must  be  processed  in  strict  superdense  time  order.  Since  the  timestamp  of  the 
token  from  the  feedback  loop  is  identical  to  that  of  the  trigger  input,  the  increment  in  the  microstep 
provides  the  needed  sequential  ordering.  The  process  of  checking  for  these  causality  loops  is  part 
of  the  Causality  Analysis  block  of  Figure  4. 

The  tape  trigger  event  is  also  sent  to  the  TimeDelay2  actor.  This  actor  increments  the  times¬ 
tamp  by  the  last  value  provided  by  an  event  on  the  port  on  the  bottom  side  of  the  actor.  This  value 
is  produced  by  the  actors  on  the  path  starting  with  the  tdc  sensor  input.  The  TimeGap  actor  out¬ 
puts  the  time  interval  between  successive  tdc  signals,  which  from  Figure  5  represents  the  rotation 
period  of  roll  A.  This  value  is  multiplied  by  the  fraction  of  a  period  represented  by  the  tapeToCut 
angle  thus  yielding  the  correct  delay  for  the  tape  sensor  to  the  cut  actuator  path.  Similarly,  the 
bottom  path  computes  the  paper  velocity  output  based  on  the  radius  input  from  sensor  J  and  the 
rotation  period. 

4.1  Experiment  design 

To  test  the  proposed  design  environment,  code  was  generated  from  the  Ptides  model  of  Figure  6  for 
two  very  different  execution  platforms.  Simulation  and  execution  results  are  shown  in  Figure  7.  The 
microprocessor  on  the  Renesas  platform  [16]  is  a  typical  embedded  controller  found  in  industrial 
applications.  The  clock  and  timing  functions  discussed  in  section  2.2  were  implemented  using  timing 
hardware  in  the  DP83640  Ethernet  PHY  of  Texas  Instruments  [17]  used  as  the  Ethernet  interface 
on  the  Renesas  platform.  The  second  test  platform  used  an  XMOS  multicore  microcontroller  [18] 
that  provides  up  to  8  hardware  supported  threads  of  execution.  XMOS  devices  execute  with  single 
cycle  execution  of  instructions  and  therefore  provide  very  deterministic  execution  timing  for  the 
code  generated  in  this  experiment. 

In  this  experiment,  the  external  input  signals  tdc,  arm  and  tape  were  generated  using  National 
Instruments  PXI  cards  in  lieu  of  using  an  actual  flying  paster.  These  inputs  and  the  resulting 
outputs  contact  and  cut  were  captured  using  an  oscilloscope.  In  Figure  7  the  first  set  of  inputs 
show  the  signals  tdc  followed  by  arm  and  tape  each  separated  by  50/us.  The  resulting  outputs 
contact  and  cut  follow  the  tape  signal  by  200/is  and  500/US  respectively.  The  second  set  of  inputs 
consist  of  the  tdc  and  tape  signals  but  since  there  is  no  arm  signal  there  are  no  outputs.  In  Figure  7 
the  timescales  of  the  top,  middle  and  lower  panels  are  in  ms,  p.s,  and  ms  respectively  resulting  from 
the  different  measurement  instrumentation  used  for  each.  Note  that  the  plots  for  the  simulation 
and  for  execution  on  the  two  platforms  are  identical  in  spite  of  the  very  different  architectures  and 
capabilities  of  the  two  execution  platforms.  Although  not  visible  at  the  scale  of  these  plots,  the 
results  were  precise  to  8ns  on  the  Renesas  platform  using  the  DP83640  and  to  a  similar  precision 
on  the  XMOS  platform. 

In  XMOS,  if  more  than  four  hardware  execution  threads  are  active,  the  throughput  of  each 
thread  is  reduced.  The  XMOS  plot  shown  is  for  the  case  where  four  threads  are  used  for  the 
execution  (but  not  always  active).  Although  not  illustrated,  we  also  compiled  the  code  for  two 
other  cases:  using  all  eight  hardware  threads  and  utilizing  a  second  core.  The  resulting  10  timing 
from  each  case  is  identical,  even  though  the  execution  timing  varied. 

The  invariance  of  the  external  timing  with  respect  to  changes  in  platform  capability  results  from 
the  properties  of  the  Ptides  actors  discussed  in  section  2.  Consider  the  token  (true,  100/is,  1)  placed 
on  the  event  queue  at  the  tape  sensor.  The  token  (true,  100 fis  +  tdctocutdelay,  1)  =  (true,  600/its,  1) 
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Figure  7:  Flying  paster  results 


produced  at  the  output  of  actor  TimeDelay2  is  applied  to  the  cut  actuator  at  time  600/rs  on  the 
clock  of  the  controller  platform.  Note  that  the  time  r  that  this  token  was  produced  on  the  output 
of  actor  TimeDelay2  is  lOO^s  <  r  <  600/US.  For  a  slow  processor  r  will  be  closer  to  600/its  and  for  a 
fast  processor  closer  to  100/xs  but  as  long  as  r  <  600 /is  the  external  timing  specifications  are  met. 
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4.2  Insights  gained 

External  timing  accuracy  depends  on  the  implementation  of  the  architecture  features  discussed  in 
connection  with  Figure  2.  These  features  can  be  implemented  in  software  but  the  latency  and  jit¬ 
ter  will  reduce  the  accuracy  compared  to  the  hardware  assisted  approaches  demonstrated  in  these 
experiments.  Less  obvious  are  the  other  time  constraints  imposed  by  the  implementation  architec¬ 
ture.  For  example,  if  the  interfaces  used  by  software  to  acquire  sensor  data  or  cause  actuation  have 
excessive  latency  this  reduces  the  available  software  execution  time  and  therefore  may  preclude 
a  feasible  schedule  during  schedule  analysis.  Likewise,  the  safe-to-process  analysis  at  a  multiport 
actor  requires  that  the  execution  be  postponed  for  the  computed  real-time  delay.  The  value  of 
this  delay  is  relative  to  the  time  of  the  platform  clock  and  for  efficient  implementation  requires  a 
low  latency  read  path  to  this  clock.  This  suggests  that  external  hardware  should  have  a  memory 
mapped  interface  to  the  platform  clock  and  sensor  and  actuator  registers  rather  than  the  serial  or 
network  path  interfaces  often  found. 

5  Conclusions  and  future  work 

We  outlined  the  principal  ideas  of  the  design,  simulation,  and  code  generation  environment  for 
Ptides  and  illustrated  how  it  is  used  on  a  simple  example.  This  example  describes  functional 
and  timing  behavior  in  a  platform-independent  way.  A  comparison  of  simulation  results  with 
results  from  executions  from  two  very  different  implementations  of  this  example  shows  that  correct 
functional  and  timing  behavior  can  be  achieved  and  the  generated  code  exhibits  identical  timing 
at  the  cyber-physical  boundary  on  the  different  implementation  platforms.  Specifically,  network 
latency  and  clock  synchronization  error  must  be  bounded  and  the  platforms  must  be  capable  of 
executing  the  code  within  the  design  times.  It  is  also  possible  to  detect  timing  errors  at  run  time, 
e.g.  errors  introduced  by  transient  out  of  specification  network  delay.  These  characteristics  are 
valuable  in  a  variety  of  application  domains  such  as  test  or  control  systems  where  deterministic 
timing  is  critical  and  must  be  invariant  over  changes  in  internal  component  design,  upgrades  in 
microprocessor  speed  and  the  like. 

The  Ptides  principles  should  also  allow  machine  readable  timing  interface  specifications  to  be 
created  for  devices.  This  raises  the  possibility  of  designing  components  and  systems  that  can  do 
run  time  checks  for  timing  feasibility.  This  possibility  and  the  investigation  of  optimum  designs  for 
the  hardware  support  of  Ptides  semantics  provide  interesting  opportunities  for  future  research. 
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